Manufacturing Control System Principles Supporting Error Recovery

Most Manufacturing Control Systems 0VICS) commercially available lack support for error recovery. Even normal constructs for encoding exception handling, a natural part of many computer languages, are absent. Although several proposals have been suggested, there are still shortcomings: ̄ although many proposals contain support for error recovery or fault tolerant operation, most of the support only concerns the assembly plan/activities of the manufacturing process, such as what to do when a grasp operation falls (e.g. [Cao and Sanderson, 1992; Delchambre and Coupez, 1988; Gaspart et. al., 1989]). However, after a structural failure such as a broken air pressure hose, and subsequent repair, parts of the machinery may be in an abnormal state (i.e. not passed during normal execution), or in a normal state but not corresponding to the ’state’ of the program execution a situation seldom addressed. ̄ they are often tedious to instruct, not to mention the effort needed to modify the system. One problem is that the knowledge used when instructing a MCS is to a large extent lost at coding/compile time i.e. it is not explicitly needed/represented in the systems normal instruction formalism, and thus not available for further usage. As a result of this, many earlier attempts to provide support for error recovery often result in multiple representation of the knowledge ( .g. [Lee et. al., 1983; Schmidt, 1992; Srinivas, 1977; Srinivas, 1978; Taylor and Taylor, 1988; Taylor et. al., 1990), implying extra overhead when the system changes and the knowledge base is to be updated. A prime example is the usage of an external expert system responsible for detecting anomalies and for producing recovery actions, hooked on to an existing controller. A small change of the program in the controller results in major rewritings of the expert system. However, there are approaches where knowledge is reused (e.g. [Gini, 1983]) or integrated as a part of the instruction formalism ([Chen and Trivedi, 1991; Delchambre and Coupez, 1988; Gaspart et. al., 1989; Meijer and Hertzberger, 1988; Meijer et. al., 1991]). ̄ the competence of the user of these systems, i.e. the operator at the shop floor, is seldom reused. Most proposals presented are designed to solve the problem automatically, thus limiting their applicability. The area of error recovery may be subdivided in detection, diagnose and recovery. We are primarily interested in providing support in the recovery phase, or more precisely, providing support to change the state of the machine to be a legal one, and to synchronize the state of the current execution with the state of the machine. The goal is to minimize the time and material loss during the recovery process. The means are twofold: Firstly, the usage of an explicitly represented model of the underlying system, providing robust service for a task level instruction system as well as a semantic framework for any planning or plan repair activity. Secondly, a task level where the activities, their causal relation and what object or type of object they use are logged in order to extract information about the normal behavior of the system. The next section presents an overview of Aramis (A Robot And Manufacturing Instruction System), which is specification, programming and execution environment for manufacturing applications. The following section describes the recovery support (which will be1) provided by the system.